1. Field of the Invention
The present invention relates to computer software, and deals more particularly with techniques for efficiently updating rendered content (such as content of a Web page) using a “slow-loading” content element (e.g., a slow-loading image).
2. Description of the Related Art
The popularity of computer networking environments has increased tremendously in recent years, due in large part to growing business and consumer use of the public Internet and the subset thereof known as the “World Wide Web” (or simply “Web”). Other types of computer networking environments, such as corporate intranets and extranets, are also increasingly popular. As solutions providers focus on delivering improved Web-based computing, many of the solutions which are developed are adaptable to other computer networking environments. Thus, references herein to the Internet and Web are for purposes of illustration and not of limitation. (Furthermore, the terms “Internet”, “Web”, and “World Wide Web” are used interchangeably herein.)
Most modern computing applications render their displayable output using a graphical user interface, or “GUI”. In a computer networking environment such as the Internet, client software known as a “browser” is typically responsible for requesting content from a server application and for rendering the information sent by the server in response. Commonly, the rendered information is formatted as a Web page, where the layout of the Web page is defined using a markup language such as Hypertext Markup Language (“HTML”). (References herein to rendered content are in terms of displayed HTML Web pages, although this is by way of illustration and not of limitation.)
Many client/server applications that operate in computer networking environments need to asynchronously update a GUI displayed on the client, based on (for example) some change in the server. Examples of this type of application include system monitoring applications such as Tivoli Business Systems Manager and Tivoli Enterprise Console® (which may need to asynchronously display alert notifications to a system administrator); messaging/chat applications such as Lotus Sametime® (e.g., to display an indication of which people on the user's instant messaging buddy list are currently available for instant messaging); and so forth. (“Tivoli Enterprise Console” is a registered trademark of International Business Machines Corporation and “Sametime” is a registered trademark of Lotus Development Corporation.)
In the prior art, applications that need to asynchronously update a displayed GUI at a client typically use one of the following techniques to perform the update:
1) The client binds to a socket address and listens for connections from the server. In this approach, the client starts a listening thread attached to a socket. When an update occurs, the server creates a connection to the port where the client is listening, delivers the update notification, and then disconnects.
2) The client polls the server. In this approach, the client connects to the server periodically to check for updates, and then disconnects until the next polling interval. Typically, client polling results in downloading content without regard to whether it has been updated.
3) The client maintains a persistent connection to the server. Here, the client connects to the server and “subscribes” to be notified of updates. When an update occurs, the server sends an update notification over this already-existing connection.
When the client application is a Web interface (e.g., HTML displayed in a Web browser), there is still often a need to asynchronously update the client's displayed GUI. Examples of such scenarios include any application where at least some portion of the content delivered to the client for rendering via the Web interface is dynamic in nature—such as stock ticker feeds, weather forecasts, etc. (as well as Web versions of the previously-described monitoring and chat scenarios). FIG. 1 shows a sample Web page layout 100 that has a header 110, body 120, and footer 130. In addition, a dynamic content area 140 is rendered in the upper right portion of the display. This dynamic content area 140 may be structured as a frame within page 100, and might be used to display a stock ticker with stocks the user wants to monitor, or the current temperature in the user's location, and so forth. However, the techniques described above for asynchronously updating a GUI display become much more problematic and difficult to implement in the Web environment, largely because the underlying technologies (the Hypertext Transport Protocol used for message delivery, the HTML notation, and the JavaScript® scripting language, in particular) don't readily facilitate these types of interactions. (“JavaScript” is a registered trademark of Sun Microsystems, Inc.)
It is not possible to use the first technique listed above (where the client listens for server connections) without introducing a Java™ applet, and using an applet in this way is often not possible since an applet that performs this type of privileged operation would require a cryptographic signature on the applet as well a hole in the client's firewall. When using the second technique listed above (where the client polls the server), a great deal of unnecessary network traffic can be generated, and the server can easily get overloaded. Client polling can also cause the GUI to flicker, and can interrupt the user's interactions with the Web page (since the page is suddenly and abruptly refreshed). These disadvantages often make the third technique listed above (use of a persistent connection) the most attractive. (“Java” is a trademark of Sun Microsystems, Inc.)
A commonly-used implementation of the third technique is a technology known as “pushlets”. Pushlets basically use an HTML frame to display the client's HTML and a hidden HTML frame to maintain a persistent connection to a servlet. The connection remains persistent because the servlet never closes the output stream of the HttpServletResponse that is destined for the hidden frame. Instead, the servlet holds onto this output stream and whenever a client update is needed, the server sends JavaScript commands to the hidden frame, where this JavaScript contains the updated HTML. A JavaScript listener function in the hidden frame receives the JavaScript commands, and uses Dynamic HTML (“DHTML”) to replace the contents of the visible frame accordingly. Refer to “Pushlets-Whitepaper”, by Just van den Broecke, published Aug. 6, 2002 by Just Objects B. V. on the Internet at http://www.pushlets.com/doc/ whitepaper-all.html for more information on pushlet technology.
However, there are several problems with pushlets, several of which are described in the above-referenced white paper on pushlets. These problems include:
1) Interference from content buffering. The HTTP framework was not designed for persistent connections, so the content of an HTTP response is often buffered by some component of the network. Buffering may be introduced by an HTTP proxy server, network cache, or even the servlet engine's HTTP server. This buffering can delay the client update, or even prevent it altogether.
2) No reconnect mechanism is available. Again, since the HTTP framework was not designed for persistent connections, the HTTP server and/or client often terminate an HTTP request if it has been running for too long. It is also possible for the user to accidentally (or purposefully) terminate the persistent HTTP request by pressing the “Escape” key or the “Stop” button. When the HTTP request ends in this way, the client has no way to automatically reconnect the persistent connection to the server, or to signal the user that he has caused a disconnect.
3) Client memory leaks may occur. When using pushlets, the hidden frame is receiving new HTML strings to display in the visible frame. These HTML strings become part of the JavaScript that is contained in the hidden frame's Document Object Model (“DOM”). The browser will not free memory associated with a DOM until the page containing that DOM is reloaded. Since the hidden frame is not reloaded, the memory footprint of the browser can grow without bounds. (Hereinafter, the terms “refresh”, “redraw”, and “reload” are used synonymously when referring to redisplaying content.)
4) Cross-browser issues with DHTML support. While a standard version of DHTML is promulgated by the World Wide Web Consortium (“W3C”), different browser vendors have provided their own unique extensions. These vendor-specific extensions complicate efforts to deploy pushlets uniformly across all browser platforms.
Accordingly, what is needed are improved techniques for asynchronously updating rendered content, while avoiding drawbacks of prior art approaches.